Saltar al contenido principal

Grupo 10

En este documento vamos a encontrar el feedback recibido por el grupo 12

Semana 1​

Presentación​

  • Incluir un opener para atraer la atención del público al comienzo de la presentación
  • Mejorar la entonación para no aburrir al público y demostrar comienza y seguridad
  • Reducir la cantidad de texto en las diapostivas

Business Statement​

  • Dejar bien claro cúal es nuestra idea clave de negocio

Análisis de Riesgos​

  • Tener muy en cuenta el riesgo de comunicación con la ONG

Casos de Uso​

  • Tenemos una funcionalidad demasiado simple
  • Proponer expansiones de funcionalidad a la ONG

Tecnologías​

  • Los canales de comunicación no son muy profesionales y nos recomiendan usar Slack

Semana 2​

Presentación​

  • Hacer uso de expresiones más profesionales (Ej: "Económicamente sostenible" en vez de "Que no les cuest mucho dinero")
  • Evitar disonancia entre lo que se está contando y lo que muestran las diapositivas
  • Usar "undergraduated" en vez de "future" cuando nos llamamos ingenieros

Business Statement​

  • Añadir el contexto de la herramienta (Ej: Las aplicaciones que tiene la ONG actualmente)

Análisis de Riesgos​

  • Mejorar planes de contigencia para que sean más claros y efectivos, no solo una reunión para estudiar la situación en todos los casos
  • Tener en cuenta en los planes de contigencia los roles del equipo
  • Tener en cuenta el "Bus Factor" en el riesgo de "Ausencia de Personal"

Análisis de Costes​

  • No es lo mismo la estimación del TCO que el presupuesto, hay que estimar el coste total de propiedad y justificar los precios
  • Realizar la diapositiva de la estimación de costes usando una tabla con los gastos más detallados
  • Se recomienda que mostremos el coste por mes

Matriz DAFO​

  • Enlazar nuestras debilidades con las oportunidades y nuestras amenazas con nuestras fortalezas para dar a entender la solidez de la idea de negocio y como solventamos nuestras vulnerabilidades

Commitment Agreement​

  • Mostrar el estado actual de incumplimiento en cada presentación de seguimiento

Mockups​

  • Mostrarlos siempre al final de la presentación

Dashboard​

  • Muy positivo que hayamos mostrado el dashboard, añadirlo siempre a partir de ahora

Casos de Uso​

  • Añadir más funcionalidad (Ej: Puntos calientes, Grado de accesibilidad de un edificio, Municipios sin el plan aceptado, etc)
  • Proponer expansiones de funcionalidad a la ONG

Semana 3 (Test 1)​

Presentación​

  • Tener cuidado con las imágenes de personas que usamos en la presentación
  • Evitar texto pequeño en las diapositivas
  • Recomendable ensayar al menos una vez con otra persona del grupo delante
  • Usar IA para apoyo en la presentación principalmente para el síntesis de la información
  • Si usamos códigos QR en nuestra presentación tener cuidado de no ponerse delante

Usuarios pilotos​

  • Realizar un cuadro de mando con los usuarios pilotos

Documentación​

  • Gestionar la documentación con estrategias de código (Markdown, ramas propias, etiquetas, etc)
  • En el sprint 3 hay que tener los manuales usuarios hechos para las ONG

Medición del Rendimiento​

  • Tener en cuenta que diferentes roles pueden precisar de diferentes maneras de medir el rendimiento

Retroespectiva​

  • Al igual que el rendimiento es diferente dependiendo de los roles (Mostrar diferencia tiempo entre lo estimado y lo real -> Reloj horas)

Commitment Agreement​

  • Contemplar el grado de compromiso del Commitment Agreement en la presentación

Análisis de Riesgos​

  • Decir el estado actual de los riesgos

Código​

  • Tener un changelog entre sprints (Releases)

Landing Page​

  • Poner enlace al Clockify

Semana 4​

Presentación:​

  • Fluidez en la presentación

Usuarios piloto:​

  • Formularios para los usuarios pilotos
  • Buscar diferentes perfiles
  • Agenda de usuarios pilotos -> Cuando y qué tocan (Ir avisando no muy concreto)

MVP:​

  • Visualmente está feo, ponerlo de manera más visual
  • Demostrar que da valor al negocio y hace que tenga éxito

Análisis de costes:​

  • TCO: Coste de propiedad, están los costes iniciales fijos y luego los costes por mes como mantenimiento
  • Mostrar en la siguiente el OPEX (Operación) y TCO (Inversión Inicial)
  • Realizar Comparación TCO real y estimado
  • Ya que estamos más avanzados en el proyecto realizar estimación de gastos y ingresos estimando una cantidad de usuarios y con visiones pesimistas, optimistas y realistas
  • Evolución TCO según usuarios

Mockups:​

  • Decidir si enseñar un vídeo o en vivo

Análisis de riesgos:​

  • Evaluación de la respuesta al riesgo (¿Funcionó? ¿Cómo de bien?)

Sprint Retroespective:​

  • Decir claro el objetivo del sprint

Medición Rendimiento:​

  • Mejorar la diapositiva
  • Diapositivas con gráficas anónimas del rendimiento de cada individuo o subgrupo
  • Mostrar evolución respecto a la semana anterior

Medición calidad:​

  • Implementar analizadores de código (Comparaciones con futuros sprints)
  • Mencionar cuántos test tenemos (Esto no lo dijo pero lo incluiría)
  • Usar dashboard de BlueJ (Theory pill) para seguimiento (Mide las buenas prácticas)

Sprint Backlog:​

  • Tener en cuenta que el Sprint 2 hay más tiempo
  • Mostrar reloj de avance y comparar
  • Sprint Backlog 2 detallado ya
  • Mencionar priorización tareas backlog

Commitment Agreement:​

  • Bien nuestra sección de CA
  • Mostrar el nivel de compromiso de la gente (Quién quiere el 10 y quien quiere aprobar)

Landing Page:​

  • Poner el clocki en nuestro Docusaurus personal no en la LP

Despliegue:​

  • Dicen que van a actualizar el documento de despliegue (A la espera de que lo suban)

Otros:​

  • Gestión tareas por GitHub y dejar constancia de todo (dudas en comentarios de issues y eso)
  • Aplicar estrategias de ramificación y código a documentos (Cree un Docusaurus personal para nosotros y lo estoy poniendo listo para empezar a subir nuestros documentos)

Semana 5​

Presentación​

  • NO cambiar la presentación entregada, ni siquiera el orden de las diapositivas
  • Entregar el vídeo/demos a partir de ahora incluso si ocupa un montón
  • Incluir los vídeos en las diapositivas y salirte de ellas para mostrarlo

Análisis de Costes​

  • Poner el coste de electricidad y agua está bien
  • Las diapositvas de CAPEX y OPEX está bastante compacto, nos recomiendan separarlas un poc (Decían de ponerlo de forma tabulada)
  • No nos ha pasado a nosotros pero importante tener en cuenta que los CAPEX son las cosas que son de nuestra propiedad/capital tras el gasto, Github por ejemplo no es CAPEX
  • Para los planes de contingencia evaluar si son CAPEX o OPEX porque depende del tipo de plan

Usuarios pilotos​

  • Nos recomiendan tener un archivo o herramienta de monitoreo (Un excel estaría bien)

Gestión de código​

  • Tenemos que tener un repositorio muy bonito
  • Usar conventional commits, plantillas de issues, dejar constancia en las issues de las dudas, etc...
  • Buscar que licencia le vamos a dar a la ONG

Dashboard​

  • El reloj de horas actual no está muy claro visualmente, se recomienda coger el de clockify
  • Añadir número de comentario en issues

Otros​

  • La diapositiva de status del Github Project les ha gustado mucho, quieren que también enseñemos las etiquetas y decir si hay plantilla
  • Recomiendan que se usen patrones de diseño para aquellos que tienen problemas de interdependencia entre Backend y Frontend
  • En la sección de QR les han recomendado a otros grupos poner en el enlace al Clockify con las horas ponerlas por persona en vez de solo el total

Semana 6 (Retroespectiva)​

  • Aún no esta disponible

Semana 7​

Presentación​

  • No mencionar el Backlog del 1 (Recomendación mía)
  • Vídeo incluirlo en la presentación sin salir de las diapositiva (feedback pasado)
  • Incluir métricas de rendimiento de equipo y calidad
  • No siguen el orden de la guía de presentación
  • No hay gráfica de comparación de gastos
  • No hay estructura del equipo
  • Darle la vuelta a los porcentajes en el CA
  • Poner versión del CA
  • Poner formulita de cálculo de porcentaje en el CA
  • Reloj del proyecto (Una diapositiva dedicada)
  • Lecciones aprendidas
  • API al OPEX si la usamos

Semana 8​

Presentación​

  • El killer opener era muy parecido al business statement, haber pasado las diapositivas antes y acabar el KO y BS a la vez
  • De Storyboard nos recomienda un rol diferente -> Profesional o el Alcalde apuñalado
  • Cambiar mantenimiento por despliegue en OPEX
  • Lecciones aprendidas despúes de hablar de los problemas, no del planning, para quede reflajado de donde vienen
  • Las lecciones aprendidas que tenemos son en verdad los problemas, decir como gestionamos este problema en concretitud (Riesgos)
  • Cambiar tabla por algo de ticks porque quitan la atención del que habla al texto
  • El color en donde la tabla de colores y las xs cambiarlo, los porcentajes están al revés
  • Actualizar las tablas en la diapo del github project

Demo​

  • La demo se ve muy pequeña, poner lupa y menos resolución para aprovechar el espacio

Rendimiento​

  • Tener en cuenta las responsabilidades de cada persona para el rendimiento

Costes​

  • Añadir coste de API al Opex en el sprint 3

Usuarios pilotos​

  • Decir como gestionamos el feedback, si hemos recibido el feedback y que acciones tomamos en consecuencia

Semana 9​

Presentación​

  • Falta Storyboard en forma de anuncio y en vídeo
  • Inconsistencia en la historia del Storyboard
  • Diapositiva reloj de horas y gestión de problemas hay que explicarla y no pasar por encima
  • Gráficas: Los ejes y colores no se ven bien, uniformidad forma y estilos en la medida de lo posible
  • Vocalización y que se nos entienda mejor, más ensayos para que salga de manera natural el cambio de diapositiva
  • El texto largo roba la atención, lo suyo sería evitar tenerlos

Demo​

  • Muy rápida
  • Explicar términos y condiciones
  • En la demo algunos colores de letra no se ve bien (Público)
  • No les gusta el diseño de tener los formularios centrados
  • Hacer zoom en algunas partes
  • Descripción de que se va hacer al principio
  • Quien está logeado (No hace falta decirlo, puede aparecer en el vídeo)
  • Enseñar principalmente lo nuevo lo demás muy por encima

Costes​

  • Cambiar forma de explicar los costes
  • Lo que mostramos son más los Ingresos que Beneficios cambiarlo
  • Decir que los costes seguridad social no están incluidos en el cálculo

Usuarios pilotos​

  • Mostrar priorización del feedback

Semana 10 (Revisión Sprint 3)​

Presentación​

  • Sincronización lo que se dice con lo que hay escrito
  • Texto grandes decirlo en su idioma o no ponerlos

Demo​

  • Enlace argumental Demo-Strotyboard para mantener una cohesión sería lo ideal.

Anuncio/Storyboard​

  • Se tiene que sentir más cercano
  • No tocar temas controversiales

Costes​

  • Se recomienda el cálculo y adición de los costes sociales al documento de Análisis de Costes.

Usuarios pilotos​

  • Decir que se va implementar a futuro en relación al feedback de los usuarios piloto

Marketing​

  • Se pedían ideas preliminares de la campaña de marketing

Semana 11​

Presentación​

  • Problema de planteamiento: Visión de que es la última presentación, primera vez enseñando al mundo
  • No referencias a nada anterior
  • Debe haber hilo argumental entre demo y anuncio, ir a lo principal
  • Cuidado con el audio y eco (Probarlo antes en el WPL)
  • Poner caras en la diapositiva de miembros de grupo

Costes​

  • CAPEX y OPEX no se conoce las siglas en el WPL, hablar de costes de capitalización y coste operacional

Anuncio/Storyboard​

  • El vídeo de inversores encapsula perfectamente lo que hace cocemfe, pero el anuncio de usuario no

Usuarios pilotos​

Marketing​

  • Buena segmentación de mercado
  • Vídeo de inversores al uso se puede hacer como los otros grupos, hacer uso de las gráficas hablando del retorno de inversion recompensas por inversión y demas conceptos de dinero
  • Acciones para atraer posibles inversores: Invertir dinero en el proyecto, apelar al sentimiento de que damos apoyos a ONGs

Semana 12​

Presentación​

  • La demo debe tener algún tipo de historia coherente con la utilizada para el killer opener o el anuncio a ser posible
  • La demo actual lo único que hace es enumerar lo que se hace sin enseñar un caso de uso real
  • No usar términos técnicos
  • Dejar claro quién es el público objetivo (En nuestro caso son las ONGs principalmente pero estamos abiertos a otras empresas que quieran comprar nuestro producto)
  • Quitar lo de ISPP de la portada al principio

Costes​

  • Decir si las estimaciones de costes tienen en cuenta la segmentación o no